WORLD INTELLECTUAL PROPERTY ORGANIZATION 
International Bureau 




PCX 

INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(51) Interxiationai Patent Classification 6 
G06F 12/14 



Al 



(11) International Publication Number: WO 97/04394 

(43) International Publication Date: 6 February 1997 (06.02.97) 



(21) International Application Number: PCr/AU96/00440 

(22) International Filing Date: 12 July 1996 (12.07.96) 



(30) Priority Data: 
FN 4186 
FN 9866 



14 July 1995 (14.07.95) AU 

15 May 1996 (15.05.96) AU 



(71)(72) Applicant and Inventor: DRAKE, Christopher, Nathan 
[AU/AU]; G.F.O. Box 343, Sydney, NSW 2001 (AU). 



(81) Designated States: JP. European patent (AT, BE, CH, DE DK 
ES, FI, FR, GB. GR, IE, IT, LU, MC. NL, FT. SE). 



Published 

With international search report. 



(54) Title: COMPUTER SOFTWARE AUTHENTICATION, PROTECTION. AND SECURITY SYSTEM 
(57) Abstract 

A software-based computer security enhancing 
process and graphical software-authenticity method, 
and a method to apply aspects of the two are dis- 
closed. The process provides protection against cer- 
tain attacks on executable software by persons or other 
software used on the computer. Software using this 
process is protected against eavesdropping (the mon- 
itoring of software, applications, the operating sys- 
tem, disks, keyboard, or other devices to recoixi (steal) 
identification, authentication or sensitive data such as 
passwords, User-ID*s, credit-card number and expiry 
dates, bank account and PIN numbers, smart-card data, 
biomelric information (for example: the data compris- 
ing a retina or fingerprint scan), or encryption keys), 
local and remote tampering (altering software to re- 
move, disable, or compromise security features of 
the altered spftware) examination (viewing the exe- 
cutable program, usually with the intent of devising 
security attacks upon it), tracing (observing the op- 
erating of an executable program step-by-step), and 
spoofing (substituting counterfeit software to emulate 
the interface of authentic software in order to sub- 
vert security) by rogues (e.g.: Trojan Horses. Hack- 
ers, Viruses. Terminate-and-stay-resideni programs, 
co-resident software, multi -threaded operating system 
processes. Worms. Spoof programs, key-press pass- 
word captures, macro recorders, sniffers, and other 
software or subversions). Aspects include executable 

encryption, obfuscation, anti -tracing, anti -tamper and - 

self-verification, rimtime self-monitoring, and audiovisual authentication (math, encryption, and graphics based method permitting users to 
immediately recognise the authenticity and integrity of software). The figure in the specification depicts the many components and their 
interaction. 
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Background Of the invention 

The present invention relates to a computer program having enhanced security features, and 
also to a system and method for enhancing the security features of a con^uter program. In particular, 
the present invOTtion relates to such a program, and the system and method for creating the program, 
having increased security features to prevent ID-Data (as defined hereafter) eavesdropping and/or theft 
and/or to ensure authenticity. 



Description Of The Prior Art 

Computers are becoming widely interccxinected and heavily rebed upon to process and store 
sensitive informaticxi. The risk of unauthorised access to con^}uters and informatics has increased 
with this increased intercomiectivity. 

1 5 Many security advances exist in the areas of identification & authaitication of users, 

cryptography, virus prevention, and the like, however - almost all of these advances ultimately rely 
upon computer software. Most computer systems are, or are accessed by, small personal coitputers, 
and most software used on these personal computers is susceptible to "local attacks" - attacks v^liich 
are mounted from inside said personal computers against said software by other software or people. 

20 Passwords, User-ID*s, credit-card numbers and expiry dates, bank account and PIN numbers, 

smart-card data, biometric information (for example: the data conq>rising a retina or fingerprint scan), 
cryptographic keys, and the like are all examples of identification, authentication or similar data whidi 
is either sensitive in itself, or may allow access to sensitive, restricted or other information or services. 
Hereafter, the term ID-Data will be used to refer to the abovementicmed idaitification, authentication 

25 or suTular data, excluding ID-Data which is valid only for a single use, or which is designed to expire 
at regular intervals of less than two minutes. 

Illegal access to computer system information can be obtained by exploiting various security 
flaws ft^und in conr^uter software products. A common flaw is the susceptibility of said software to 
the theft of ID-Data either directly from said software as h executes, or firom the operating system or 
30 hardware on which said software is executing. Another commcxi flaw is the suscqjtibility of said 

software to illegal modification. Such modificatic»)s may remove, disable, or conpromise the security 
features of said software. 

Viruses, Terminate-and-stay-residoot programs (TSRs), co-residait software, multi^readed 
operating system processes, Trojan Horses, Worms, Hackers, Spoof programs, key-press password 
35 capturers, macro-recorders, sniffers, and the like can be effective at stealing ID-Data and are 

examples of (a) rogue software or (b) pec^le capable of subverting security software or (c) software 
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which can be configured for illegitimate puiposes Hereafter, the term rogue software wiU be used to 
refer to software or subversions such as the abovementioned (a) (b) and (c), used ft>r the purpose of 
steahng ID-Data. Tbe definition of our term "rogue software'* when used herem also includes 
software or other means used to tan^r with other software. The term tan^ring is defined hereafter 

> There are many ways to introduce rogue software into a ccoi^uter system. Viruses ^read 

automaticaUy by introducing themselves. Trojan-Horses are usuaUy introduced by tricking users into 
allowing thrai to execute (such as by masquerading as a new or weU-known computer game or other 
product). Existing security problems may be utilised to introduce rogue software; some well known 
problems include Java bugs, errors, or oversights, ineffective physical security (ft>r exan5>le: 
permitting rogue software to be introduced directly on floppy disk by an intruder), electronic mail 
attachments which automatically execute or execute after a single mouse-chck, incorrect security 
settings on internet, world-wide-web, TCP/IP or modems, and tanq>ering (see definition hereafter) with 
legitimate software in-transit as it flows fi^om remote internet sites into a users computer, to name a 
few. 

1 5 Rogue software, once introduced, can steal ID-Data as mentioned hereinbefore. It may monitor 

keyboard (for exan^le: by recording every key, as the user presses each one, in order to steal a 
password as it is being typed in), serial-port, mouse, screen, or other devices to steal ID-DaU directly 
fi^om thOTi. It may monitor other software, applications, the operating system, or disks to steal ID- 
Data from there also. Once stolm, this ID-Data may be stored locally (ft>r example: in memory or oti- 

20 disk) or transmitted to remote locations (for exan^le: by modem or network) or used immediately to 
perform iUegal c^eratioos. Hereafter, the term eavesdropping wdl be used to refer to the monitoring 
of a computer to record ID-Data. 

For example, a key press recorder could secretly, and unbeknown to the computer user, record 
all the keys pressed by the user mto a hidden systems file. The inft>rmation recorded could include a 
25 user's password and other smsitive informaticxi which an organisation would obvioxisly wish to 
protect. 

Additionally, rogue software may remove, disable, or compromise existing computer software 
security features by modifying the memory, disk, or odier image of said con^uter software Rogue 
software may also utilise tampering techniques to aker existing computer software in order to steal ID- 
30 Data fi-om it, or may attach itself to existing ccm^uter software (as is the case with many con^uter 
viruses) Hereafter, the term tampering will be used to refer to the abovementicned modification of 

con^uter software— Tampering n^y take pb«^ 

exan5)le: at cme of the points v^ch a cong>uter program passes throu^ as it is being download). 

Further, counterfeit software can be substituted for legitimate software. The counterfeit will 
35 appear real to a cwnputer user, but actuaUy acts to subvert security, such as by stealing BD-Data. 
S<xnetimes caUed "Spoof programs or Trojan Horses, counterfeit software of this type may invoke 
the original legitimate software after having stolrai ID-Data, so as not to arouse a users suspicicm. 

Another potential security flaw found in computer software products is susceptibility to 
examination and reverse-engineering. Known (but generally secret) and other security problems or 
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mistakes can be discovered by hackers and the Uke from the examtnation of existing con^juter 
software and by tracing its operabon. 

AdditicHially, Con^uter software piracy is a growing problem, and the existing sini^ie means 
which prevent ibis problem (sudi as registratioD or serial numbers and customer-names being encoded 
5 within the product) are beccMtiing less eflfective. 

There is necessity within the try-before-you-buy software market for vendors to employ 
effective features which aUow old software to expire without fear of hackers or Ae like removing said 
expiry features and for secure registration of software to be provided throug^i the use of software 
unlock-codes. 

1 0 There is also need for sofhvare to be able to prevait security attacks upon itself (ie: tampering) 

and upon its own attack-detection code. There may also be a future need for software to identify the 
attadcer for subsequott prosecution. 

There also exists cases where untanq>erable software usage metering may be desirable, and 
where efiBxtive passwoond-protection of software executioD may also be desirable. 

1 5 Known advances in certain areas of conq>uter security have been successful and documented. 

There have been some advances in anti-virus tedmology whidi help detect and prevart certain security 
problems. There have been numerous advances in hardware-assisted computer security add-cxis and 
devices, such as smartcards and bicnnetric input devices. There have been advances in cryptographic 
techniques. Generally, all of these advances require authentic, un-tampered-with computer software in 

20 order to woric. There have been relatively few advances in software-based integrity self-checking (eg: 
tan^>er protection), and no prior software-based advances in prev^ting eavesdropping or the 
electronic theft of ID-Data, and no prior software-based advances in self-authentication. 



Summary Of The Ihn/EhmoN 

25 This inventJOTi describes a process v^ich substantially enhances the security of computer 

software (hereafter referred to as the improved process) and a method by whidi to apply said 
improved process (hereafter referred to as the applicator). 

The improved process cmsists of including con^uter code to automatically detea tan^>ering of 
said computer sofiAvare, and con^uter code to prevent tiie theft of ID-Data by replacing existing 
30 vulnerable (to rogue software eavesdropping or attack) software or c^erating system code with secure 
equivalents ^ich utilise anti-spy techniques (as described later in diis document). 

Preferably, the itiq>roved process also consists of including con^uter code to prevent de- 
con^ilatioQ, reverse-engineering, and disassembly by the inclusion of obfuscating code inserts, and the 
use of executable encryption. 

35 Preferably, the improved process also consists of including code to prevent execution-tracing 
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and debugging by the use of code designed to detea and prevent these operations. 

Preferabiy, the improved process consists of, or also includes, human-recognisable audio-visual 
components which permit the authQiticity of said computer software to be easily verified by the user 
on each invocation using tediniques described later in tiiis document. 

5 The idea which lead to the creation of this invaitic«i can be summarised as follows:- If a piece 

of con^uter software tibat is executing can be shown to be the genuine article, and this software can 
protect itself against eavesdropping, and this software can prevent tampering of itself, thoi is it 
possible for this software to function in a secure manner, even within an insecure operating system. 
This invfflticn permits the creation of such a piece of computer software - having a tangible, useful 
10 security advantage and hence in^roving its value. 



BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 illustrates the standard operation of a computer system known in the prior art; 

Fig.2 illustrates the known operation of a rogue or "spoor program; 
1 5 Fig.3 illustrates appUcation code updated with the preferred embodiment; 

Fig. 4 illustrates the known c^eration of a rogue eavesdrc^ping program; 

Fig.5 illustrates the interaction of the components of the updated application; 

Fig 6 illustrates the gaieral structure of the preferred embodiment of the applicator; 

Fig.7 illustrates a standard layout for a program to be executed on a con^uter system; 
20 Fig. 8 illustrates the standard layout of an EXE header under the MS-DOS c^erating system 

Fig.9 illustrates a standard layout of an EXE program under MS-DOS; 

Fig. 10 illustrates an ahered executable form COTStruaed in accordance with the specific embodiment; 
Fig.l 1 illustrates a first stage of execution of the new.exe executable; 
Fig. 12 illustrates a second stage of execution of the new.exe executable file; 
25 Fig. 13 illustrates a third stage of execution of the new.exe executable file. 



DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

As will be described hereinafter, the presort invention has general applicability to many 
different c^rating systems inchiding Microsoft DOS (Trade Mark), Apple Macintosh Operating 
30 System, Unix (Trade Mark) etc. 

Described hereafter are several security-enhancing tedmiques to combat eavesdrc^ping. 
Security is provided by (a) hankering examinatic«i of software-code or operating system code or parts 
thereof throu^ the use of the encrypticxi or partial OTcrypticxi of said code, (b) preventing the 
disass^bly of said code througji the inclusion of dummy instructicHis and prefixes and additional code 
35 to mislead and hamper disassembly (ie: obfuscating inserts), (c) prevCTting the computerised tracing of 
the execution of said code (for example: with code debugging tools) through the use of instructions to 
detect, mislead, and hairq>er tracing, (d) preventing tampering of said code through the use of scanning 
to locate alteratioDS, either or both on-disk and in memory either once at the start of execution, or 
continuously upon certain evaits, or (e) preventing ED-Data theft throu^ the inclusion of secure 
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input/output routines (for example: routines to bypass Ae standard operating system keyboard calls 
and use custom-written higjier-security routines as a replacement) to replace insecure computer- 
system routines. Hereafter, the term anti-spy will be used to refer to any combinatioo of one or more 
of the abovementiooed techniques [(a) through (e) or parts thereof] used to prevent eavesdropping. 

5 Referring now to Fig. 1 Aere is illustrated the standard scenario for "running" a given 

executable program 16, under the control of a computer operating system 17 on a computer 1 8. In the 
preferred embodiment of Ae present invention, the executable program 16 is subjected to modification, 
as will be described hereinafter, to ensure its integrity and improve its security. 

There are five a^>ects of this inveodons improved process, although said process is stiU 
10 substantially improved even if not all of them are present. These aspects are: (1) Preventing 

eavesdrc^ing (2) preventing disassembly and examination (3) detecting tan^ering (4) preventmg 
execution-tracing and (5) ensuring authenticity. 

The preferred embodiment of these aspects of the present invention will now be described. 

Aspcct 1. Frcventing eavesdropping. 

15 As hereinbefore described, it is desirable to prevent rogue software fi*om eavesdropping on ID- 

Data. By r^lacing software which is vulnerable to eavesdropping with equivalent software which is 
for more secure, this purpose is achieved. To remove the vulnerability fi*om said equivalent software, 
replacement routines may communicate directly with the hardware of the coiTq)uter (for example, they 
may communicate with the keyboard circuitry instead of using the system-supplied (and hence 

20 possibly insecure) application interftice keyboard-entry ftinction-calls.) while disabling system 

interrupts which would permit rogue software to eavesdrop. Said rq[>lacement routines are coded to 
store ID-Data retrieved in a secure manner. ID-Data is not stored in fiiU in plaintext (ie: unencrypted) 
in system or apphcation buffers. 

Aspect 2 Preventing disassembly and examination. 

25 As hereinbefore described, it is desirable to hamper disassembly (or de-compilatioo or reverse 

engineering) to protea software against eavesdropping and tan^ering, and to hinder exanunation of 
said software w^iidi mig^ lead to secret security problems or mistakes being disclosed. 

Obftiscating inserts can successfully prevent aut<Hnatic disassembly. Obfiiscatioo is adiieved 
by following unconditional jump instructions (for example, Intel JMP or CLC/JNC combination or 
30 CALL (without a return expected) or any flow-of-control altering instruction which is known not to 
return to the usual place) with one or nwre dummy c^-code bytes which will cause subsequent op- 
codes to be erroneously disass^bled (for exan^le, the Intel OxEA prefix will cause disassembly of 
the subsequent 4 op-codes to be incorrect, displaying them as the oflfeet to the JMP instruction 
indicated by the OxEA prefix instead of the instructions they actually represent). 

3 5 Dummy instructions may also be included to hanper disassembly by deliberately misleading a 

disassembler into believing a particular flow of control will occur, when in fiact it will not. 
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FIow of control can be designed to occur based upcHi CPU flag values determined from 
instrucdoDS executed a long time ago. Together with tracing prevention, this makes manual 
disassembly nearly in^>ossible. 

The majority of the executable portions of the software can be encrypted for external storage 
5 The decryption taking place in-memory after the software is loaded from external sources, under the 
control of a decryptioo *lieader" which prevaits its own tan^ering and disassembly etc. This makes 
manual and automatic disassembly nearly impossible, since the decryptioo should be designed to fail if 
tampering or tracing is detected. 

Aspect 3 Detecting tampering. 

10 As hereinbefore described, it is desirable to detect tampering, since this may lead to the 

reduction of software security 

This can be achieved with the use of code vviiich is protected from disassembly and examinaticHi 
througli obfuscaticxi and encryption, which re-reads its own external-image and compares it with its 
known memory image or precalculated check-data to detect hot-patcfaing (ie; the modification of 
1 5 software sometime after it has been loaded from disk, but (usually) before executicHi of the modified 
section has commoiced). 

Additionally, the sofhvare can scan the memory image of itself one or more times, or 
continuously, to ensure that unexpected alterations do not occur. 

Certam modificatiwis to the extemal copy of software are reflected in subtle changes to the 
20 environment in which the modified sofhvare will be executed (for exanq>le: the size of the code, if 
altered, will be reflected in the initial code-size value supplied to the executing program being 
incorrect.). Additionally, certain modification to the operating system and environmoit of said 
software can also be monitored (for example: certain interrupt vector table pointers in Intel-processor 
appUcations) to detect unexpected changes by rogue software These dianges can also be detected to 
25 prevCTt tampering. 

Once tampenng is detected, program flow-of-cOTtrol needs to be changed so that the potential 
compromise associated with ID-Data theft is avoided This may be the security-enhanced program 
terminating with a message indicating that its integrity has been con^romised before all of the ID- 
Data is altered. Alternatively, the feet that tampering has been detected may be kept secret and the 

30-~^ID-E)ata retrievedrhoweverrimmediate^ 

prevCTting access to that whidi the now potentially compromised ID-Data would have otherwise 
allowed. This latter method allows for the possibility of security-enhanced software informing remote 
or other authorities that tampering was detected and possibly other informaticm, such as what 
q>ecifically was altered and by \vhom. Care must be taken to ensure the integrity of the "remote- 

35 informing" code before ID-Data «itry is permitted. 

It will be apparent to one skilled in the art of low-level software programming that the five 
aspects described herein may be combined to provide substantially stronger security than any aspect 
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takrai on its own. For instance, to combine tamper-daection with aicryption, the precalculated check- 
data as derived during tamper-detecdon described hereinbefore may actually be one part of the 
decryption-key v^di is required to successfully decrypt Ae remaining executable software. If 
preveuticD-of-tracing and environment characteristics (including debugger detection as described 
) hereafter) are addxrional portions of said decryption-key, it makes the determinatioo of said 
decryption-key by any person or computer program other than the secure original an extremely 
difficult, if not inq>ossible, task. 

Further, it will also be apparent to one skilled in the art of low-level software programming that 
a siiiq)le construct such as a JNE to aher program flow-of-control after tan^ring has been detected is 
insufiBcient, since the JNE construct itself is subject to tan^ering. The denryption process described 
hereinbefore is preferable since there is no single point of alteration that can possibly yield a tan^ered 
executable that would execute. Indeed, the executable protected with encryption will not even be 
transformed into its int»ded form if tampering is d^ected. 

Aspect 4 Preventing execution-traciny. 

15 Apart from "spoofing" (described in aspect 5 hereafter) the last resort of a rogue who is 

prevented from disassembly, tampering, and eavesdropping on software is to trace the execution of 
. said software in order to fecilitate Ae cort^romise of its security. Hampering tracing (tracing is 
sometimes caUed debugging) prevents this 

There are numerous methods of detecting a debug-environment (ie: what tracing is taking 
20 place). When combined with decryption and tamper-protecticn as hereinbefore described, it makes the 
rogues task of detecting and bypassing debug-detection extremely difficult. ReferOTce and examples 
to Intel and MS-DOS environments follow hereafter^ atthoug^i it will be apparent to one skilled in the 
art that tiiese and similar methods are appUcable on other platforms. 

Standard Intel x86 iirtemqjts 1 and 3 are used by debuggers to facilitate code tracing. By 
25 utilising ^ese interrupts (whidi are not normally used by normal applications) in security-enhanced 
software, it hanq^ers debugging, since built-in debugging functions are now not automatically 
available. 

Monitoring the system timer to determine if software execution has spent too long 
accomplishing certain tasks can detect a situation \^iiere code tracing has been in effect and a 
30 breakpoint was reached. 

Disabling the keyboard will hamper debu gg ers, since tracing instructions are usually issued 
from the keyboard. Similarly, disabling other places frcmi where tracing instructions are usually 
issued {eg: serial ports, printer ports, and mouse) or displayed (eg: screen) will ako han^r tracing. 

System interrupts can be re-vectored for use widiin the secure software to perform tasks not 
35 usually performed by those interrupts. Debuggers usually rely upcHi system interrupts also, so to do 
this would usually disable or destroy a debugger being used to trace the software. 
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Disabling interrupts and performing ttming-saisitive instnicticxis between them will further 
haniper debugging. When tracing software, instnictions are usually executed one-at-a-time m order 
for the user to understand Aeir operatioo. Many system interrupts must occur regularly (eg: timer and 
memory re-fresh operations), so debuggers usually do not disable interrupts even when they encounter 
5 an intemipt-disabling instruction. If timers and the like are re-vectored in two separate stages, any 
timer (etc) interrupt occurring inbetween the two stages will feil, and usually crash the computer. 
Further, interrupts can be disabled or enabled using obscure means (witfi flag-altering instructions for 
example) to hamper tracing. 

Discretely testing the status of disabled or enabled system fecilities (eg: interrupts, keyboard, 
1 0 vector-pointers) to ensure that a debug-environment has not altered or by-passed them wiU seriously 
hamper tracing also. 

Certain con^uter processors have instructicm caches. In some circumstances, it is possible to 
aker die instructions immediately before the CPU encounters them, but the ahered instruction vnU not 
be executed normally because the cadie copy has the "old" one still. In debug environments, the cache 
1 5 is usually flushed, so any altered instructions vrill actuaUy be executed. This again hampers tracing. 

Using strong cryptografrfiic sdiemes, such as DES, or RSA or the Hke will prevoit the 
examinatiOT of any decrypticm routines from reveaUng a simple patdi to disable said routines. 

Whai tracing software, the program stack is usually used by the debugger either during the 
tracing operations or at other times. This is easily detected, and by using the area of the stack which 
will be destroyed by unexpected stack-use for code or critical data, software can be designed to self- 
destruct in this situation. 



20 



Scanmng the amunand environment and the execution instructicm can detect the executicHi of 
software by unusual means. Searching for "DEBUG" in the conrmiand hne, or scanning memory for 
known debuggers for example will detect tracing. AdditiOTally, by detecting vAich operating system 
25 process initiated the load of the software, une?q>ected processes (eg: debuggers) can be d^ected. 

Monitoring system buffers (eg: the keyboard memory buffer) or hardware (eg: the keyboard 
circuity and internal buffers) for unexpected use (eg: keyboard input and processing is occurring whai 
die software is not requesting it) will also detect debuggers, whidi usually rely in part on system 
ftmctions in order to operate. 



"^^"^ Building a process or mukqjle processes wiiidra sudTaTa — 

resident or child process which executes during system interrupts or after the parent process has 
terminated will again hanger tracing. 

Bypassing system routines (eg: in DOS, using direct memory writes instead of DOS system 
calls to revector interrupts) will further han^r debugging and rogue software monitoring, as will 
3 5 unravelling loop constructs (which will make tracing long and cumbersome). 

Code checksums and operating-system checks (eg: interrupt table pointers) can be designed to 
detect debug-brealq>omt instruction inserts or other nKxiificaticms. Using the result of the checksum 
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for some obscure purpose (eg: decryption, or (much later) control-flow changes) will further hamper 
tracing. 

It will be apparent to one skilled in the art of low-level software programming that a 
combination of techniques to detect, prevent, and mislead tracing will provide a medianism making 
5 tracing very difficult, if not inq>ossible. At the very least, it will require an expert with very e?q>ensive 
tools and perhaps some understanding of tiie original software design a very long time to make any 
debugging progress - a situation which is recognised in military software security accreditation 
worldwide as higjiily desirable. 

Aspect S Ensuring autfaenticitv. 

10 In accordance with an aspect of the present inventicxi there is provided a m^od of providing 

for a secure entry of ID-Data in a computer system comprising activating a visual display or 
animation and/or audio feedback (hereinafter called an audio/visual component) as part of said 
secure entry of ID-Data so as to hanger emulation of said secuire entry process. 

Preferably, the animation includes feedback portions as part of the ID-Data entry process. 

1 5 Preferably, the animation is repeatable and varied in accordance with the information entered. 

The animation preferably comprises 2,5D or 3D animation and includes animation of any ID-Data 
input. 

Preferably, the animation is designed to tax the computer resources utilised and thereby makmg 
any forgery thereof more difficult. 

20 Notwithstanding any other forms vAiich may fell within the scope of the present invention, 

preferred forms of the invention will now be described, by way of exanq>le only, with reference to the 
accompanying drawings. 

In the preferred embodimoit of the presort invention the user interfece for the acquiring of ID- 
Data is secured whereby the duplication of the interfece is roidered mathematically con^)Iex sudi that 
25 cipher-code breaking techniques are required to produce a counterfeit look-alike interfece By making 
the authentication interfece (ie: ID-Data entry screen - for example: a logon screen or a screen for 
entering credit card details) unable to be emulated, tanq>ered with, or reversed oigineered, die 
application program allows for a higher degree of security and authenticity even in insecure 
environments sudi as the Internet or home software apphcations. 

30 Referring now to Fig.2, there is illustrated a classic form of rogue attack on a computer 

system. In this form of rogue attack, a rogue's "spoof program 22 is inserted betwe« applicatim 
software 16 and the user 23. The apphcatioo 16 normally has a portion 24 devoted to ID-Data entry 
and verification or the entry of commercially saisitive information (including passwords etc) to the 
application in addition to the apphcation code 25. The spoof program 22 is designed to exactly reflect 

35 the presCTted user interfece of ID-Data entry code 24 to tiie user. The user 23 is then fooled into 

utilising Ae masquerading spoof program 22 as if it was Ae application 16. Hence the user can be 
tricked into divulging secret information to the spoof program 22, An exanrq>le may include a classic 
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"login spoof wherein the qsoof program 22 prints the login pron^ (ie: ID-I>ata entry) message on the 
screen and the user mistakes the login prompt for a legitimate one, supplying a user name and 
password to this prpgram 22 which records this information as well as passing it on to the login code 
24 of application 16 so as not to arouse the suspicion of user 23 - or by issuing a message, such as 
5 "incorrect password, please try again" and Hien passing control to the login code 24 of application 1 6. 

Referring now to Fig.4, tiiere is illustrated a relatively new form of rogue attack 40 Tliis form 
of attack proceeds similarity to the spoof attack of Fig.2, widi the foUowing difference. Instead of a 
spoof program 22, a rogue program 41 is inserted \^ch secretly eavesdrops cn ID-Data entry code 
24, or on applicaticxi code 25, or oo operating system 17, or on hardware 1 8 or elsewhere in order to 
1 0 steal sensitive informatioo directly fixrni the legitimate supplication. Since fte legitimate ^Ucation is 
still actually executing, the users suspicicxi is not aroused, since rogue program 41 is generally 
invisible to the user 23 Akematively, executable program 1 6 may have been tan^ered with (as 
hereinbefore described) to reduce its security, alleviating the necessity for the presaice of rogue 
program 41 . 

15 In Fig.5, there is illustrated in detail the structure of an application 50 constructed in 

accordance with the preferred embodiment running on cwnputer hardware 18. Fig.5 is similar to 
Fig.4 with the in^rtant difference Aat user 23 now conununicates directly with secure drivers 5 1 
v^di are part of the secure ID-Data entry program code 3 1 whidi is utilised by the security-oihanced 
(eg: tanker proterted) appHcation code 52. It can be seen that the user 23 no longer communicates 
with the operating system 1 7 or the unprotected computer hardware 18, thus the rogue program 4 1 
can no longer eavesdrc^ on ID-Data. 



20 



In Fig.3, there is illustrated, in more general terms than Fig.5, the structiu^e of an apphcation 30 
constructed m accordance with the preferred embodimait wherein secure ID-Data entry program code 
31 is provided which is extremely difficult to rq>Iicate, eavesdrop upon or subvert. The secured ID- 
25 Data entry program code 3 1 can be created, utilising a nimiber of different techniques 

Firstly, the executable porticm of the secured ID-Data entry code can be prcrtected against 
tracing, disassembly, tampering, viewing, reverse engineering, keyboard entry theft, eavesdropping, 
hot patching and other attacks by transforming the secured ID-Data entry program code 3 1 from its 
normal executable form 16 (Fig.2) to a corresponding secured form of executable (as hereinbefore 
30 described - refer aspects 1 to 4). These techniques are preferably applied to the ^plication code 1 6 in 
general or less preferably ^ecificaUy limited to the ID-Data oitry portions 24 thereof 



Additionally, the secure ID-Data entry program code 3 1 is itself created. Tliis code 3 1 
preferably comprises a complex graphical user interfece series of screens and animatiwi designed to 
make dupUcation by a rogue thereof extremely difficult. 

35 hiitially, the ccwnplex user interfece should include fecilities to disable any frame buffer 

recording devices, the disablanent occurring before each frame is displayed. Also, where a multi- 
tasking c^rating system is in use, or where context switching is enabled, switdiing out of the 
interfece screen is preferably disabled or ID-Data oitry procedures encrypted or terminated when the 
mterfece screen is swapped out. The images presented vdiich form part of the ID-Data entry screens 
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comprise complex 3D animation sequraces having a high degree of complexity and extensive use of 
screen colours and screen resolution m addition to visual design so as to make copying thereof 
extremely difficuh. 

The conq>lex conq>uter graphics can be created utilising standard techniques. For information 
5 oa how to create conq)lex 3D imagery, reference is made to "Computer Graphics, Princ4>les and 

Practice- by Foley, Van Dam et al, pubhshed 1990 by Addiscxi-Wesley Publishing Con^any or other 
standard textbooks <hi generation of conq>uter graphics. Reference is also made to the numerous 
mtemet news groups and ardiives on graphics and games programming, specifically to: 
comp.graphics.research, comp.graphics.rendering, conq>.graphics.raytracing, ccHnp.graphics.misc, 

10 comp.gi^phics.digest, comp.graphics.animation, conp .graphics .algoritfmis, COTip. graphics, 
ah. graphics pixutils, ah.graphics, rec.games.programmer, comp.sys .programmer, 
con^.sys.ibm.programmer, comp.sys. ibm.pc.programmer, comp.os.msdos .programmer, 
comp.msdos.programmer, ah.msdos.programmer. Reference is also made to ''PC Games 
Programmers Frequently Asked QuestiOTis" document available on the internet, via 

1 5 rec .games .programmer and elsewhere . 

By encoding a complex 3D image Avhidi forms part of the ID-Data entry screens, 4e hurdle 
requirement of a rogue to reverse engineer the complex imagery is substantially increased. The 
inclusion of graphical animation is advantageous in preventing static screen shot duplication attacks 
by a rogue form succeeding 

20 As noted above, it is preferable that traditionally difficuh graphical programming techniques are 

en^loyed wherever possible, with the aim of making it more detectable for a user interacting with the 
system to discern lesser copies of the animation. Suitable 3D animation can include the introduction 
of shadows, the hating of pseudo-3D animated objects, transparent or translucent objects, shiny, 
reflective, or mirrored objects, gravitational effects in animated d>jects, single-image-random^ot- 

25 stereogram bitmaps or backdrc^s, translucent threads, eflEects, sudti as difGraction pattems, screen 
masks, backdrops, colour palette "animation", complex animated objects resistant to sin^)le hidden- 
sur&ce removal techniques known to those skilled in the art and directed to hindering dupUcation. 

Further, the animation can take into account: 

1 . Thwarting attempts at compressicxi of the ID-Data entry screms. This can be achieved by 
30 having animation wfaidi has low visual entropy and having many gr^hical elements w^ch are altered 
. firom frame to frame in a marmer which is higjily discernible to the human viewer. Apart fi'om being 
difficuh to replicate, complex 3D computer imagery having low eaticpy or redundancy will require 
large amounts of storage space for a rogue attempt at duphcation based on recording Ae screen output 
and therefore be more readily discernible to the user should this form of attack be mounted. 

35 2. The animation is further preferably designed to thwart a successful r^lay attack which is 

based on providing only a subset (hmited number of frames) of the screai animation to a viewer. This 
can be achieved, for example, by the inclusion of several animated spheres which "bounce** around the 
screen and change colours in a manner that is recognisable to the viewing user but which is not readily 
repeatable. A replay of only a subset of the screm animations to the viewer will be highl y evident in 
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this case when, upon looping, the user is alerted to a problem when the animation "skips" or "junps" 
and does not operate in a previously smooth manner. This makes it difficult for a rogue spoof 
program to copy the animation without including all parts of it. 

3 Most in^oitantly, the graphics presented can be customised to the input data entered For 
example, the information entered by a user can be rendered and/or animated by the secure ID-Data 
etmy program code 31 (Fig.3). As an exan^le, in an ID-Data entry program, when a user types in 
their user name, the animation can be created letter by letter. For exan^Ie, vAxea typing in the user 
name "CHRIS" each letter could be rendered difiereotly depending on those characters previously 
typed. For example, the letter T mi^ appear as a large "barbers-pole- which ^irals and changes 
colour, speed, size, and/or position and is slightly tran^arent, thereby allowing the animated seen 
whidi is a backdrc^ to the character to be discerned throu^ the character itself. For example, in the 
above example, the letter "I" would only appear as the specific animated barbers pole that is does if 
the previous letters entered were "C", "H", and "R" respectively. 

The utilisation of a unique sequence of animation based on a user's input of information 
15 sensitive data increases the difficulty of creating any "spoof program" attadc on the apphcation 30. 
Tliis is eq>ecially the case since the executable code of apphcation 30 is preferably in an encrypted 
form The use of animation being particular to the order in which characters arc entered is 
particularly advantageous as the computaticHial complexity of rephcaticHi is substantially increased 

A similarly effective animation technique is to produce only one graphical object after entry of 
20 each portion of ID-Data, sudi as a con^uter-generated human's face, but have the features of said 
face be determined by a hash or cryptographic funaion based upon the users input For example, 
after entry of the ID-Data "CHRIS" (in this example^ the individual diaracters may not, themselves, 
be based an the abovementiooed gmeraticm procedure) , a teaiage girl's fece widi long blonde hair 
and blue eyes may be displayed. If the *^S'* was instead a the face would be entirely different 
25 The ID-Data used for producing an object for display should not be ID-Data whidi is designed n<^ to 
appear on-screen when entered (eg: a password), since the display of a corresponding objea would 
give a rogue informatics ot which to base guesses of the secret ID-Data. 

By utilising cryptography or having complex formulas to determine the sequencing of 
animation, the rogue programming the corresponding spoof program shall have to crack the 
30 cryptographic scheme in order to get the selection of character animation corr^ for any generahsed 

attack. In the abovemCTtioned example, a rogue will have to determine the algoridmi for producing the 
^^ce,_smce^human beings are adept-at recpgm 



displayed on the screen is incorrect. Such a technique allows for a mathematically secure, visual 
method to guarantee the authenticity of the software which generates the screen feedback. The user of 
35 the software is instructed to note their own particular animation sequaice and to immediately 

discontinuing utilisation of die apphcation 30 should that sequence ever change. The user may also be 
mstructed to ccmtact a trusted person, sudi as the supplier or curator of the apphcation to COTfirm 
that the animation sequence they witness is the authentic sequence intended by said supplier. 

Further, the particular animation presented for a particular applicaticxi 30 can be forther 
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customised for each application so as to be distmct (such as by the incorporaticxi of Ae apphcations 
name as part of the anmiated image). 

Further hindrance for a rogue programmer can be created by hand coding porticHis of the 
animatioo in assembly language so as to generate the maximum possible complexity and interaction m 
► the animation with the hi^iest level of detail for individual workstation computers. This further raises 
a hurdle allowing for the easier detection of rogue spoof programs 22 which wiU often be written in a 
more convenient, higjier level language (such as C or C+-h) vMch will also operate at a different 
speed, the user being instructed to locA for speed differences. 

Further, animated scene timing can be utilised, providing anti-looping and frame removal 
detection is still catered for. The animated scene timing allows for a user to detect unexpected 
irregularities in a frequently presented animated inter&ce. By including in the animation SOTie 
dehberate regularity (such as the rhythmic convergence of some parts of the animation in one 
particular spot), a rogue programming a spoof program shall also have to duphcate the preferably 
complex timing events necessary to accomplish tiiis convergence The regular nature of the scene 
1 5 timing should be higji enough so that the user expects to see certain events and thereby making it 
difficuh for a rogue spoof program to copy the animation widiout including all parts of it . 

Preferably, where possible, all ID-Data is immediately encrypted whidi makes recovery of the 
ID-Data by a rogue througji analysis of the con5)uter program mranory difificuk. Preferably, public- 
key cryptographic methods (eg: Elliptic-curve, RSA or Diffie-Hellnian cryptography) should be used 
20 makmg it unpossible to reverse engineer the cryptographic code to decrypt any seositive information 
should it be stolen in its encrypted form. Prohibiting all or most intemq^ts whai data is to be entered 
and encrypting or hashing the sensitive information inunediately so that it is only stored partially, or m 
an encrypted form, before re-enabling interrupts is cxie exanq>}e of adiieving this objective. 

As a forther akemative, analysis of a user's personal characteristics can be included as part of 
25 the internee. This can inchide attempts at recogniticm of a user's typing style (duraticm of keypresses, 
delays between subsequent keys, dioice of redundant keys, mouse usage characteristics, etc) or by 
additional authentication techniques, inchiding smartcards, biometric inputs such as finger prints 
detectors etc. 

Further, the graphical animation routines can be "watermariced- by the secure ID-Data «itry 
30 program code in that Tiidden" infomuition may be incorporated into the scene (for exaii^>le "salted- 
checksums") to allow carefol analysis of the output of secure ID-Data entry program code 3 1 to 
distinguish between original graphics animation and counterfeit animation. For example, the hidden 
infomtadon may be oicoded in the least-significant bit of pixel data at selected locations of the 
animation. 

35 The user determinable sequence of animation can also extend to flie provided audio animation. 

For exanq>le, audio and odier feedbadc tedbniques including music and speaking tones can be played 
in response to particular key strcdce ccHnbinations. By utilising different voices and/or tones and/or 
volumes and pitches for each keystroke or combination, the security of the appUcadon 30 can, once 
again, be substantially increased. The change in voice intonation will be readily "leamt" by a user and 
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thereby further inhibit a rpgue*s abibty to dupUcate the same sequence of sounds or voices Of course, 
the Qicoding of the voice system should be in an aicrypted form. 

Further, upcm detecting any attempt to subvert the secure ID-Data entry program code 3 1 (eg: 
subsequent to detecting tanq)ering), a notificatioQ message is preferably sent to a prosecuting body or 
5 the like where the apphcation 30 is currently, or later becomes connected to a network such as the 

Internet, or by other means (eg: via Modem or by including coded informatioo in pubhc or odier files) 

For apphcatiOT programs 30 requiring activaticxi by a host program executed ot a difierent 
computer, a secure means of activation can be incorporated into Ae cliait apphcadoo 30. The host 
and chart interccmmunication can issue dialloige and response code authentication and verification 
10 utilising cryptographic systems such as public-key encrypticm and/or odier standard means of 

overcoming data replay attacks and other threats designed to trick the secure cheni apphcation 30 into 
activation. 

It would be appreciated by a perscm skilled in the art tfiat the process of coding any data entry 
process utilising these techniques, together with additional techniques to protect against recording, and 
1 5 eavesdropping, and executable protection techniques may be necessary to improve the security of tiie 
interfece. AdditicnaUy, executable encryption, additional authentication, and odier methods are 
desirable in producing the protected executable. 

It would be appreciated by a person skilled in the art that numerous combinations, variaticms 
and/or modificaticms may be made to the present mvOTticMi as described without departing from the 
20 spirit or scope of the invention as broadly described. The preseart embodiments are, therefore, to be 
considered in all respects to be illustrative and not restrictive 

SummarY of the Applicator ( of an imoroved process of security as hereinbefore described^ 

The preferred embodimoit of the present inventicMis' method (hereinbefore described as the 
"applicator'*) by which to apply an in^roved process of security (as hereinbefore described) will now 
25 be described widi reference to the accon^anying drawings. 



30- 



on 



Referring now to Fig. 7, there is shown a standard format utilised for storing executables 
disk, often occurring in the art, and in particular m ccmjunction with programs run on the above 
mentiGned operating systems. The standard executable 16 normally comprises a header section 71, a 
code sectim 72, and a data section 73. The header section 71 normally stores a standard set of 

informatitti required by the conq>uter operating system 1 7 (FigTl ) fonruDmimg"of the ex^utable~r6: 

This can include relocaticm data, code size etc. The code section 72 is normally provided for storing 
the "algorithmic" portion of the code. The data sectim 73 normally is utihsed to store the data, such 
as constants, or overlays 92 utilised by the code secticxi 72. 

Turning now to Fig.6, the preferred embodiment of an applicator program 60 is shown which 
35 takes as its input the executable program 16 and performs an obfiiscating step 61, a ciphering step 62 
and an anti-key press and autiientication step 63 (described hereafter) vAich perform various 
transformations m the executable program 16 to produce a new executable program 30. 
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The obfuscating step 61 mcxii£esthe header 71 (Fig. 7) of the executable 16 in additioa to 
inserting loading code which will be described hereinafter. The cipher step 62 encrypts the existing 
executable 16 and calculates check data (eg: a chedcsum) for tide encrypted executable. The anti-key 
press and authenticatioD step 63 replaces various insecure system calls with safe equivalent code and 
5 preferably inserts code to graphically represent the integrity of said executable program. 

The newly formed executable 30 (new.exe) can be dien stored on disk and tfie apphcator 
program 60 ccHTq>leted, the new executable 30 replacing the oki executable program 16. 

When it is desired to mn the replaconent executable prc^ram 30, the replaced executable 30 
(new.exe) executes the obfuscating code, previously inserted by apphcator 60. The obfuscating code 
1 0 initially decrypts the executable program and vaUdates the stored check-data before re^xecuting the 
decrypted executable. 

The foregoing description of the preferred embodimCTt has been in general terms and it will be 
understood by those skilled in the art that the invmtion has gaieral apphcation to many different 
operating systems, including MS-DOS, Apple Macintosh OS, OS/2, Unix etc. 

15 The most ccHTunoQ operating system utilised today is the MS-IX)S operating system This 

operating system is designed to run on INTEL xS6 microprocessors and includes a large number of 
historical "quirks'* whidi give rise to greater con^lexity than would perhaps be otherwise required 
when designing a new operating system from "scratdi". For illustrative purposes, there will now be 
presaited a specific embodimait of the preferred embodiment designed to operate under tiie MS-DOS 

20 operating system. Unfortunately, the exan^le is quite complex as it operates in the framework of the 
MS-DOS operating system. Therefore, it is assumed tiiat the reader is familiar with systems 
programming under the MS-DOS operating system. For an extensive explanation of the inner 
workings of the MS-DOS operating system, reference is made to standard texts in this field. For 
example, reference is made to "PC Intern" by Michad Tischer, pubhshed in 1994 by Abacus, 5370 

25 52nd Street, S.E. Grand Rapids, MI 495 12. A second useful text in this matter is "PC Architecture 
and Assembly Language" by Barry Cauler, pubhshed 1993 by Carda Prints, 22 Regatta Drive, 
Edgewater, WA 6027, Australia. 

The specific embodim^ of the present invention will be described with reference to altering an 
"EXE" executable prpgram under DOS in accordance with the principles of the present invention. 

30 Referring now to Fig.9, there is shown the structure 90 of an executable ".EXE" program in 

MS-DOS as normally stored on disk. Tliis structure is closely related to the structure 16 of Fig. 7 
which illustrates the more general case. The structure 90 includes a header 71, otherwise known in 
MS-DOS terminology as die program segm»t prefix (PSP). This is normally followed by a 
relocation table 91 ^wiiidi contains a Ust of pointers to variables within a code area 72 wfaidi must be 

35 updated v^rith an ofi&et address when tihe program is loaded into a particular area of memory. The 

operation of the relocation table is well known to those skilled in the art of systems programming. The 
next portion of structure 90 is the code area 72 which contains the machine instructions for operation 
on the x86 microprocessor. Tliis is followed by a program data area 73 winch contains the data for 
code area 72. Finally, there may exist a number of overlays 92 which contain code which can be 
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Referring now to Fig.8. there IS shown the stmcture of in more detail The 

table of Fig. 8 being r^roduced from page 750 of the above mentioned Tischer refermce. k should be 
noted that the header 71 includes a number of fields including, for exanq>le, a pointer 8 1 to the start of 
5 the code 72 (Fig. 7) and a pointer 82 to the relocaticm table 91 (Fig.9) 

In Ae specific embodiment, the ^plicator program 60 (Fig. 6) proceeds by means of the 
following steps: 

(1) The executable program 16 is opened for reading and a determinatiosi made of its size. 

(2) The header 71 (Fig.9) of executable program 16 is then read in and a copy is stored within 
1 0 ^hcator program 60. A c<^y of Ae header 7 1 is written out to form part 1 01 of the new.exe file 30 

as illustrated in Fig. 10 

(3) Next, from the fields 81, 82 of the header 71 (Fig. 8) a determination is made of the size of 
relocation table 91 of executable program 16. 

(4) Next, determination is made of the size of the executable code 72 and data porticos 73. 
1 5 (5) The relocation table 91 is then read into the memory of the appUcator program 60. As 

noted previously, the relocadon table 91 consists of a series of the pointers to positions within code 
segment 72 which are required to be updated whoi loading the program exe file into memory for 
execution. The relocation table is sorted 93 by address before being written out to the new.exe 
executable file at position 102. 

20 (6) As noted previously, the relocation table 91 ccmsists of a series of pointers into code area 

72. A d^ermmatiOT is made of the size of a code, known as the "netsafe 1 " code 1 04, the ccxitents of 
this code will be described hereinafter. Next, a search is conducted of the sorted relocaticm table 102 
to find an area between two consecutive pointers within code secticxi 72 whidi is of greater magnitude 
than the size of netsafo 1 code 104. This area 94, designated part B in Fig.9 is located. If this code 

25 porticmed 94 cannot be located the applicator program 60 exists with an error conditicxi. 

Upon finding code portion 94, the code porticai 95, also denoted part A is encrypted and cc^ied 
across to form new code portira 103. Code porticai 94 is then encrypted and copied to an area 105 of 
new.exe 30. The netsafe 1 code 104 is then inserted by apphcator 60. Code portion 96, also denoted 
part C is encrypted and cc^ied across to form code portiOT 106. Data portion 73 and overlay portion 
30 92 are copied into new.exe 30 as shown. A second portion of obfiiscating code, doioted "netsafe 2" 
107, the ccmtents of w^ch will be described hereinafter, is diem inserted after overlays 92 and before 
code porticHi part B 105. 

(7) The header 101 is then updated to reflect the ahered layout ofnew.exe executable 30. 
Additionally, the initial address 109 of executicm stored in header 1 01 is altered to be the start of 

35 n^safo 1 portion 104. 

(8) As mentioned before, code portions 103, 106 and 105 are subjected to encrypticm or 
enc^herment in accordance with step 62 of Fig.6. The aicrypticxi sdieme utilised can be subjected to 
substantial variation. In this embodiment, the DBS standard encryption scheme was utiUsed. This 
scheme rehes on a fifty-six bit key for encryption and decrypti<xi and is well known in the art. 
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Once encrypted, it is necessary to store the decryption key in new.exe executable 30. A number 
of different methods can be udhsed to store the key. The preferred method is to spread portions of the 
key to different positions widiin the executable 30. For example, bits of the key can be stored within 
the netsafe 1 code 104 and netsafe 2 code 107. Addidooally, bits of the key can be stored within 
5 header poition 101 Also, it is envisaged that bits of the key can be stored in the condition codes 

wfaidi are a coDsequence of execution of various instructions within netsafe 1 area 104 and netsafe 2 
area 107 and/or the operating system 1 7 (Fig.5), with Ae overaU requiiCTaeot being that the key can be 
later extracted using a predetermined algorithm. 

(9) The next st^ is to patch the address of the start of code area 72 and netsafe 2 code area 
10 107 intotfae required locations within netsafe 1 area 104. 

The netsafe 1 area is then writtai to the file containing new.exe executable 30. 

(10) The area 106 is then encrypted as aforementioned and written to the executable 30 
followed by overlays 92 and encrypted netsafe 2 code portion 107. 

(1 1) As will become apparent hereinafter, upon execution ofnew.exe executable 30, netsafe 2 
1 5 area 107 is responsible for loading code porticn 105 over die top of necsafe 1 area 104. Therefore, it 

is necessary to write the relevant addresses of the start and aid of code portion 94 to the required 
position within netsafe 2 area 107. 



20 



(12) As wiU be described hereinafter, netsafe 2 area 107 is also responsible for decrypting the 
CTicrypted portions of codes 103, 104, 105, 106, and 107 and hence the netsafe 2 area 107 must also 
store this combined code size for later use on decryption. 

Finally, a overall checksum for new.exe 30 is calculated and stored at the end of the file at 
position 108. This checksum is later used to verify the decryption procedures' success and to prevent 
the execution of "scrambled" code, whidi would be the result ifnew.exe 30 were tanq>ered with. 

As will be further described hereinafter, netsafe code areas 1 04 and 107 contain code to decrypt 
25 the aicrypted areas of the new.exe 30, to rq>atch code portion 105 back to its original position, and to 
replace potentially insecure routines or easily spoofed screens normally utdised by the apphcation (eg: 
unsafe keyboard drivers) with an alternative safe form of routine. 

Upon executioo of the new.exe executable 30, die executable starts at the start of netsafe 1 , area 
104 (Fig. 11), as this address has been previously patched into position 109 (fig. 10) of header 101 
30 (Fig. 10). The netsafe 1 area 104 then performs the following stq>s (Al) to (AlO): 

(Al) The first step is to disable all the interrupts apart Grom those necessary for continued 
operatioo of the computer device 18 (Fig. 1) (for example, memory refi-esh cannot be disabled). The 
disabling of interrupts includes the disabling of die keyboard interrupt in order to stop amateur "code 
snoopers" fran determining the operation of the code area 104. 

35 (A2) The next step is to interrogate the calling environment of the operating system stack to 

ensure that the program new.exe was not called by a debugging program which is tracing the 
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operation of new.exe. AdditiCMialiy, the data variables necessary for operation of netsafe 1 code area 
1 04 are defined to be on the operating system stack (Refer Address OEH and lOH in Fig. 8). TTiis 
stack will change unexpectedly \^en in a code snoc^ing or debugging environment and will cause the 
debugger to crash, thmby stopping a k from fbUowing the operation ofnew.exe executable 30 

5 (A4) The intern^ trap addresses are then altered in a two stage process. The first stage resets 

a first part of the SEG:OFF address format and occurs at this point with a second stage occurring at a 
later time as will be fiirther described herein below. By staging the aheratioo of interrupt trap 
addresses, any code snooper will be finther confiised as said trap addresses will initially be garbage. 

(AS) Any input fiom the keyboard is fiuther disabled by informing the MS-DOS operating 
10 systan to ignore any received keys. 

(A6) The second stage of the revectoring of the normal debugging interrupts is then applied so 
that the normal debugging interrupts can be used by the decryption code, to be described hereinafter, 
thereby nnaking debugging abnost impossible. 

(AT) A check is then made to ensure that the above processes have been successfixl in that the 
1 5 debugger interrupts do net point to any d^mggers, the keyboard is still disabled and the operating 
system has disabled the acceptance of keys firom Ae keyboard. 

(A8) The key for decrypticm is tiien reconstructed utilising the reverse process to that utilised in 
storing tiie informaticHi located in the key. 

(A9) Turning now to Fig. 11. there is shown the standard format of the executable new.exe 30 
20 when executing in memory. As will be well known to those skilled in the art, an executing program 
under the MS-DOS system will include a stack 1 1 1 and work space 112 A memory allocation 
(Malloc) call is then done to set aside an area 1 13 for the loading in of Ae netsafe 2 code 107 of 
Fig. 10. The disk copy of new.exe 30 (having die fonnat shown in Fig. 10) is thOT opened by Ae 
netsafe 1 code 1 15 and an encrypted copy of netsafe 2 code 107 (Fig. 10) is then loaded in fi-om the 
25 disk file, decrypted and stored in memory area 113. The relocatable pointers of the code contained 
within the netsafe 2 code 1 13 are then updated to reflect the position of the executable in m«nory. 

(A 1 0) Control is th^ passed to netsafe 2 code 113. 

The code area netsafe 2, 1 13 then performs the following st^s (Bl) to (B4): 



(B I ) The portion of code of the disk c<^y daicted part B, 1 05 (Fig. 1 0) is read in from disk in 
30 an encrypted format and written over the old netsafe 1 code 115. 

(B2) As will be further described hereinafter, the netsafe 2 area 113 includes a number of 
keyboard routines \^^ch are preferably stored in an encrypted format. Therefore, the next step is to 
apply the decryption to any of the encrypted areas of netsafe 2 code area 113. After decrypticm. the 
netsafe 2 area 1 13 is checksunmied and the result is tested against a prestored checksum to ensure the 
35 integrity of netsafe 2 area 113. 



BNSDOCID: <WO 970-t394A1 I > 



wo 97/04394 PCT/AU96/00440 

- 19- 

(B3) The disk copy of the new.exe is ihm again read m and checked against prestored check 
data to ensure that it has not been dianged. Additionally, an attempt is made to read past the md of 
file of the disk copy of new.exe 30 (Fig. 10) to ensure that no extension (eg: viral) has occurred. 

(B4) The encrypted portions of die menrKiry copy (Fig. 11) ofnew.exe are then decrypted 
5 utilising the key and once decrypted, the decrypted portions are again diecked and tested against 
predetermined data. 

The next step in execution of the netsafe 2 code 113, is to rq>lace insecure (eg: keyboard) 
system routines with a more secure method. Referring now to Fig . 12, there is diown the current state 
of the new.exe executable in memory. The insertion of die more secure system routines then proceeds 
10 in accordance with the following steps (C 1 ) to (C5): 

(CI ) Firstly, a second memory allocaticxi is done to set aside an area 5 1 (Fig. 13) for the 
storing of the secure hardware routines (eg: keyboard). These routines are then copied fi-om their area 
within netsafe 2 code 113 to die memory area 51. 

(C2) Next, the ID-Data entry routines which are normally activated by the in te rr upt table 131 
1 5 when dealing with ID-Data input are altered sudi that, rather dian pointing to corresponding areas of 
die MS-DOS operating system 17, they point to the corresponding secure area 51. These interrupts 
include interrupt 9 whidi occurs when a key is pressed on a keyboard, interrupt 29h which reads a key 
and interrupt 16h ^iiich tests for the presence of a key. 

(C3) The executable 30 (Fig. 13) is then ready for execution and the registers are initialised, the 
20 memory area 1 1 3 deallocated & control passes to the original start address of executable program 1 6 

(C4) It will be evident, that when executing, all keyboard calls (or other ID-Data entry calls, if 
other than keyboard) will be passed to keyboard (or other) routines 51 with the keyboard hardware 
being interrogated directly by keyboard routines 5 1 to return information to the calling program. 
Keyboard routines 5 1 include a copy of the correct interrupt vector addresses for each keyboard 
25 routine and each time they are called, a check is made of the interrupt table to ensure that it has not 
been altered. Preferably, keyboard routines 5 1 protect the keyboard hardware by issuing controller 
reset or similar cmnmands to flush the keyboard data out of the circuitry after said data is retrieved to 
prevent hardware eavesdropping, or routines 5 1 utihse the protected mechanisms of the central 
processor to protect said hardware from eavesdropping. 

30 (C5) When the executable 30 terminates, interrupt 2 Ih (an MS-DOS standard) is called. This 

interrupt is also revectored to a corresponding area of routines 5 1 . The termtnatim code of keyboard 
routine area 51 restores the correct interrupt pointers in interrupt table 131 to point to the MS-DOS 
operating system 1 7, and clears the no-longer-needed program and data firom memory before returning 
to Ae DOS operating system by calling the real interrupt 21. 



35 



The foregoing describes only one particular CTnbodiment of the present invention, particubrly to 
the operation of the MS-DOS operating system, h will be evident to those skilled in die art, tiiat the 
princ^les outlined in the particular embodiment can be equaUy applied to other operating systems in 
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accordance with the objects of the present invention. Further, modifications, obvious to those skilled 
in the art, can be made thereto without departing from the scope of the invention. 

EXPLANATION AND PURPOSE OF CLAIMS 

Claims 1,2, and 3 are independent. The invention in claim 1 covers any hi^ security software 

> protecting ID-Data by utilising anti-spy techniques, and tamper-protecting itself Claim 2 is for a 
method of producing higji security software, such as, but not limited to, that in claim 1 . Claim 3 is for 
a new process of graphically representing the authenticity of higji security software, such as, but not 
limited to, that in claim 1 or produced by claim. 2. 

Claims 4, 5, 6, 7, 8, and 9 add preferred components to the high-security enft)rcing functions of 

► the software in claim 1 Claim 10 adds a tracing^reventicxi preferred cconponoit to claim. 9 

Claims 1 1, 12, 13, 14, 15, 16, 50, and 53 add preferred coirqjonents to the security-applicator 
method of claim 2 

Claims 1 7 to 49 inclusive and claims 5 1 & 52 outlines the specific area of protection that this 
invention affords a con^uter program acting as a user inter&ce (eg: ID-Data entry screen). 
Specifically, they specifies how this invendoo apphes in the areas of protecting an interface against 
counterfeiting (i.e. : hampering the possibility that a fake copy of said interfece can be successfully 
presCTited to a user to fool said user into aitenng information into the fake interface), and protecting 
an mterface against malicious (or otherwise) tampering, examinaticxi, emulation, and eavesdropping 
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CLAIMS 

1 . A hi^ security executable program comprising: 

(a) purpose-writtm computer input routines within or accessed by software cxi a computer system for 
the entry of ID-Data (as hereinbefore defined), and 
5 (b) anti-spy techniques (as hereinbefore defined) within said input routines ^^di prevent or hamper 
eavesdrof^ing (as hereinbefore defined) on said ID-Data, and 
(c) tanq>er-detecdon techniques (as herembefore defined) within or accessed by said software to detect 
tampering (as hereinbefore defined) and techniques which, upon detection of tan^ring, either 
disallow the subsequent entry of ID-Data into said input routines, or ^^di invalidate said ID-Data 
10 in order to disallow current and subsequent access to that ^v^cfa said ED-Data would have 
otherwise allowed 

2. A method of altering an original executable program to form an altered executable 
program having increased security, said method comprising the steps of: 

(a) inserting obfiiscating code into a first number of precktermined areas of said executable program; 
IS and 

(b) encrypting portions of said executable program for later decryption upon execudcn; 

such that, upon execution of said altered executable program, said execurion includes the stqjs of: 

(c) decrypting the altered executable program; and 

(d) restoring said altered executable program to said original executable program 

20 3. A method of providing for a secure entry of input information in a computer system 

comprising: 

(a) activating a visual di^lay or animation and/or audio feedback (hereinafter called an audiovisual 
component) as part of said secure entry of input information so as to hamper emulatim of said 
secure entry process; and 

25 (b) audio/visual component feedback of two or more of: 

(c) all or part of said input information; 

(d) all or part of information based upon some transformation of said input information; 

(e) all or part of some transformation of all or part of the software comprising said audioAasual 
component and/or the computer operating system upon whidi said audioAisual conq>onent 

30 operates. 

4. A method as claimed in claim 1 additionally including the replacement of code vAiidt 
is vulnerable to eavesdropping (as hereinbefore defined) with equivalent code which removes said 
vutoerability; said equivalent code v^ich communicates directly with the hardware of the computer 
while disabling system interrupts or other fimctions which would permit rogue software (as 

35 hereinbefore defined) to eavesdrop. 

5. A method as claimed in claim 1 additionally including one or more automatic 
disassembly (as hereinbefore defined) tedmiques of (a) obfiiscating inserts (as hereinbefore defined), 

(b) dunmiy instructions (as hereinbefore defined), or (c) executable encryption (as hereinbefore 
defined) 

40 6. A medKxl as claimed in claim 1 additionally including code to detect tampering (as 

hereinbefore defined) by re-reading its own external-image or its internal memory image and 
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comparing said image or a calculated check of said image with pre-calculated check-data or known 
identical equivalents. 

7. A method as claimed in claim 1 additionalty including code to automaticaUy memory- 
scan the said software one or more times before or during execution of said software to detect 
5 tan:q>ering (as hereinbeft>re defined). 

8 A method as claimed in claim 1 additiooally including code to store or communicate 

details of detected tampering fyr lat^- examinadcxi, said details including all or part of said tan^ered 
software, and/or ether information available to said tampered software fiisn said computer system 

9. A method as claimed in claim 1 addrtionaliy including code to prevent, or detect and 
subsequently prevent tracing, or mislead code debuggers and execution tracing by utilising debu^r 
trap facilities for the normal operation of said security-enhanced software, and/or monitoring system 
timers or including timing-sensitive instructions or monitoring CPU stack contents or monitoring 
system buffers to detect the activity of code debuggers, and/or disabling facilities including the 
keyboard, serial pcMts, printer pcHts, mouse, screen or system interrupts in cmlertohan^r code 
15 debuggers, and/or testing that the disabled status is still true of said fecilities to detect code 

debuggn^s, and/or utilising system interrupts wfaidi would cmhnarily be used by code d^Higgers for 
the custom purposes of said security-enhanced software, and/or utilising CPU instruction cadies 
tc^etfaer with self-modifying code to mislead code debuggers, and/or scanning or interrogating the 
(grating system or executable-load-process to detect code debugger instructicxis or envircHunents. 

20 10 A method as claimed in claim 9 additionally including a process or multiple processes 

wiiich are resident or child processes of said security-enhanced software which execute during 
systCTi interrupts or after the parent process has terminated in order to hamper tracing. 



11. A method as claimed in claun 2 wherein said obfuscating code includes replacement 
25 codes for insecure system routines and said execution further includes the step of: (e) replacing the 

execution of said insecure system routines with said replacement codes. 

12. A method as claimed in claim 2 wherein said sXeps (c) and (d) occur while 
simultaneously substantially disabUng eavesdropping on the operation of said steps (c) and (d) by 
any rogue program. 

^ 3 . A method as claimed in claim 2 wiierein said step (a) inchides inserting a portion of 
said obfuscating code into Ae code area of said original executable program. 



14. A method as claimed in claim 1 1 wherein said step (e) includes altering porticms of 
an interrupt vector table to point to said replacement codes. 

15. A method as claimed in claim 2 herein said step (b) includes the storing of a 
35 decryption key in a plurality of predetermined areas of said altered executable program. 

16. A method as claimed in claim 1 5 wiierein said predetermined areas include the 
condition codes of predetermined instructions of said altered executable program. 
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17. A method as claimed in clami 3 wherein said audiovisual component has repeatable 
characteristics during subsequent invocations of said artry process, such that said audiovisual 
compooQit on each invocation of said Kitry process has a predetermined resemblance to the 
audiovisual con^onent of all other mvocaticxis of said entry process. 

5 18. A method as claimed in claim 3 wherein said audiovisual conq>ooeat is varied in 

accordance with the information entered. 

19. A method as claimed in claim 3 wherein said audiovisual ccmiponent comprises 
moving parts and/or includes 2.5-dimensioQal animation or 3-dimeasional animation. 

20. A method as clauned in claim 3 wherein said audiovisual component includes a 
1 0 representation of said input information. 

21. A method as claimed in clami 20 wiierein said mput information represaitation 
COTiprises (a) display of a single graphical object and/or (b) production of a single audio-feedback 
sequence, after the entry of all or part of said input information. 

22. A method as claimed in claim 20 vdieretn said input information representation 
1 5 includes anrniatioo of input characters and/or audible or other feedback determined by input 

characters. 

23. A method as claimed in claim 22 \^^erein the representation of said input characters 
varies for each character based on the resuh of a predetermined transformatiOT of the preceding 
imputed characters. 

20 24. A method as claimed in claim 23 wherein said transformaticxi utilises cryptographic 

or hashing methods . 

25. A method as claimed in claim 3 wherein the ease by which faithful rephcaticxi of said 
audiovisual componOTt is substantially reduced by inclusion in said audiovisual component the 
techniques of on screen shadow rendering and/or spot or flood scene fighting effects and/or seme or 

25 object shading and/or transparent or translucent objects and/or shiny, reflective, or mirrored objects 
and/or real-time animation rougjily obeying real world gravitaticMial effects and/or single-image- 
random-dot-stereogram bitmaps or backdrops and/or partial scene masking effects and/or full or 
partial scene distortion or diffraction effects and/or animated objects designed to resist sinq^le 
hidden-surface removal techniques and/or animated bitmaps and/or audible echo effects and/or 

30 difiering audio voice effects and/or differing audio volume and/or differing audio tones or pitdies. 

26. A method as claimed in claim 3 wherein said audiovisual con^>onCTt is immediately 
recognisable to human beings and includes information \>^ch identifies to the user the application to 
^^^ich said audiovisual compon^t belongs. 

27. A method as claimed in claim 3 ^^ilerein the ease by v^idi faithful rephcatim of said 
35 audiovisual component is further reduced by inclusion in said audiovisual cmiponents animation 

object movement timing such that at near regular and fi^quent intervals regularities occur which are 
obviously recognisable to users of said entry process. 

28. A method as claimed in claim 3 A^erein said entry process including said audiovisual 
component utilises a substantial portion of the computational resources of said computer system. 
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29. A method as claimed m claim 3 wherem said mtry process code responsible for said 
audiovisual component is coded in the assembly language of the computer system. 

30. A method as claimed in claim 3 wherein recording said audiovisual component by 
said computer system is disabled. 

5 31. A method as claimed in claim 3 wherein (a) the fecility to suspend or swap-out said 

entry process is either disabled, or (b) immediately upcxi suspension request, said entry process is 
protected against subsequent examination by encryptiOT or by termination and removal from 
manory of said eatry process, or (c) -where the facility to allow the central processor or processors 
of said computer system to execute code other than the code of, or the code necessary for said entry 
10 process is either disabled or else said entry process is protected against examination. 

32. A method as claimed in claim 3 A^iierein said entry process hampers simple recording 
by utilising the maximum practicable use of audiovisual framerate, and/or audiovisual resolution, 
and/or screen colours, and/or audiovisual design in said audiovisual compcxient on said computer 
system. 

15 33 . A method as claimed in claim 3 wherein said entry process hampers the compression 

of recorded output from said audiovisual component by utilising high audiovisual entropy and/or by 
the inclusion of random or other noise in said audiovisual component. 

34. A method as claimed in claim 3 \^^erein said audiovisual componait includes 
continuous output such that the looping of only a subset of said output shall not reproduce a copy 

20 largely indistinguishable to said audiovisual component. 

35. A method as claimed in claim I or claim 3 wherein said ID-Data or said input 
information is encrypted with some cryptographic process or hashed immediately upcHi OTtry and a 
plain text equivalent is not stored by said computer system. 

36. A method as claimed in claim 35 wherein disablement of one or more interrupt 
25 instructions (or equivalent CPU devices) is utilised to protect said cryptographic or said hash 

process of said ID-Data to hamper the recovery of said ID-Data by processes other than said entry 
process. 

37. A method as claimed in claim 1 or claim 3 \s^erein said input routines or said secure 
CTtry process prevents the re-vectoring of system interrupts in order to protect said ID-Data or said 

30 input information from being stolen, by means of re-applying interrupt vector pointers one or more 

times and/or by means of examining interrupt assignm^ts in order to perform a predetermined 
: „ function should the expected-assignments be altered: 

38. A method as claimed in claim 1 or claim 3 wherein in order to further authenticate 
and/or idmtify said user, additional aspects of said ID-Data or said input information are used 

3 5 including the duration of individual key presses and/or mouse button presses and/or the delay 

between subsequent individual key presses or mouse button presses and/or the user's seleaion of 
particular keys vAiea more than one equivalent exists and/or the acceleration or velocity 
characteristics of mouse usage and/or v^ere said input information includes information from other 
sources including biometric and/or smartcard information. 
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39. A method as claimed in claim 1 or claim 3 wherem said input routines or said secure 
entry process authenticates itself using (a) executable code cbedcsums of RAM or other images of its 
own executable code and/or data, (b) and/or con^ariscHi of memory with other stored copies of said 
executable code, (c) and/or decrypdon of said entry process (d) and/or detection of executable 

5 tanq>enng by examination of the executable*s environment (e) and/or con^arison of executable size 
with expected vahies (f) and/or by attempting to read past die end of the executable file to determine 
that the size is correct; parts (a) thixnigh (f) occurring either upon initial load or during or after 
execution one or more times or continually during execution. 

40. A method as claimed in claim 1 or claim 3 wherein said input routines or said secure 
10 entry process makes use of system interrupts to mcnitor itself in order to detect aheratioo of itself. 

41 A method as claimed in claim 39 or claim 40 AJviierein said input routines or said 
secure entry process incorporates means by \siiich to notify and/or transmit audientication failure 
details to a diird person or process should said self authentication fail. 

42. A method as claimed in claim 1 or claim 3 wherein said input routines or said secure 
1 5 entry process records a log of the usage and/or details of the user of said input routines or said 

secure entry process. 

43 , A m^od as claimed in claim 1 or claim 3 wherein said input routines or said secure 
entry process incorporates warnings within the executable image indicating that examination and/or 
tampering is prohibited. 

20 44. A method as claimed in claim 3 wherein said audiovisual componait cmtains 

watermaric information incorporated into the scene to allow close inspection of said audiovisual 
compfflimt to distinguish between tfie genuine process and a close rephca. 

45 . A method as claimed in claim 1 or claim 3 wherein said input routines or said secure 
entry process's loading and/or decryption routines are stored within the executable image in sudi a 

25 way as they initially replace other entry process routines and upcxi successful decryption and/or 
authentication, said other entry process routines are replaced. 

46. A method as claimed in claim 1 or claim 3 viierein said input routines or said secure 
entry process han^rs executable-code tracing through control-flow dianges in debug environmmts 
or throu^ disabling one or more system interrupts and/or disabling the keyboard and/or disabling 

30 the mouse or other input devices and/or makmg use of the program stadc ix>inter to discem existence 
of a debug environment and/or utihsing debug intemipts for program code operation and/or self- 
modification of executable code and/or examination of CPU flag registers and/or verification of 
disabled interrupts still-disabled state and/or verification of disabled keyboards stiU-disabled state 
and/or loading additional executable code into manory during execution. 

35 47. A method as claimed in claim 1 or claim 3 v^erein the executable image of said input 

routines or said secure entry process includes obfuscating assembly language dunmiy operation 
codes or instruction prefixes inserted after one or more unconditioaal brandies to hanger executable 
disassembly and/or decoiq)ilation and/or reverse engineering. 
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48. A method as claimed in claim 1 or claim 3 wherein said input routines or said secure 
entry process is securely aaivaied by its aaivation process and/or a host or server computer using a 
challenge/response activation protocol or using public or private key cryptographic methods. 

49. A method as claimed in claim 1 or claim 3 wherein said input routines or said secure 
5 entry process is stored outside of said computer system memory in encrypted form and/or v4iere said 

entry process employs techniques to hinder executable-code tracing and/or executablenxKle 
disassembly or disclosure or decompilation and/or executable-code tampering and/or executable- 
code hot-patching and/or reverse-engineering and/or pre, in, or post-execution executable-code 
recording, cop>iiig, eavesdropping or retrieval and/or theft of said input information from keyboard 
1 0 hardware or software or drivers. 



50. A method as claimed in claim 2, 11, 12, 13, 14, 15, or 16 further comprising the 
insertion of one or more compc«ients as claimed in claims 1. 4, 5, 6, 7, 8, 9, 10, or 5 L 

51. A process as claimed in claim 3, 1 7, 1 8, 1 9, 20, 2 1 , 22, 23, 24, 25, 26, 27, 28, 29, 
15 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, or 49 fimher con^rising 

protecting all or part of said input routines or said secure entry process with zero or more 
componaits as claimed in claims 1, 4, 5, 6, 7, 8, 9, 10, or 0. 

52. A method for providing for the secure input of information into a computer system, or 
A higji security executable, substantially as herembefore described with reference to the 

20 accompanying drawings. 

53. A method of altering an original executable program to form an altered executable 
program having increased security, substantially as hereinbefore described with reference to the 
accoii^)anying drawings. 
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